home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 869 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  6.5 KB
  1. Path: nntp.teleport.com!sschaem
  2. From: sschaem@teleport.com (Stephan Schaem)
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Re: PPC compilers
  5. Date: 12 Jan 1996 12:29:05 GMT
  6. Organization: Teleport - Portland's Public Access (503) 220-1016
  7. Message-ID: <4d5k6h$a2j@maureen.teleport.com>
  8. References: <john.hendrikx.40ka@grafix.xs4all.nl> <jasonb.820051107@cs.uwa.edu.au> <VBzVx*M3f@yaps.rhein.de> <4d0tf0$i4i@maureen.teleport.com> <jasonb.821371468@cs.uwa.edu.au>
  9. NNTP-Posting-Host: linda.teleport.com
  10. X-Newsreader: TIN [version 1.2 PL2]
  11.  
  12. Jason S Birch (jasonb@cs.uwa.edu.au) wrote:
  13. : sschaem@teleport.com (Stephan Schaem) writes:
  14.  
  15. : >Arno Eigenwillig (arno@yaps.rhein.de) wrote:
  16. : >: Don't distract, this was not the point. Intentional misunderstandings
  17. : >: prove nothing.
  18.  
  19. : > It was about: "C is better because you dont need to know your variable type"
  20.  
  21. : No, it wasn't, which is what I've been repeatedly saying. It was about
  22. : whether assembler is easier to debug than C because the line:
  23.  
  24. : move.w (a0)+,(a1)+ 
  25.  
  26. : tells you how many bytes are being moved, and added to a0 and a1,
  27. : whereas:
  28.  
  29.  It tells me that I move a word from a0 to a1 and let point a0 and a1 to
  30.  the next word. (I just happen to know word is 2 byte:)
  31.  
  32. : *a++ = *b++;
  33.  
  34. : does not. Many of us said "no", not least because the assembler line
  35. : doesn't tell you whether you *wanted* to move two bytes or not unless
  36. : you know what a0 and a1 are pointing to. You need to know that to know
  37. : if it's correct, just as you need to know that *a and *b are the same
  38. : type, although in the C case you *don't* need to know how many bytes
  39. : are moved or added to a and b - you don't need to know how the types
  40. : are *implemented*, and the claim was made that, in any case, you could
  41. : pretty much rely on C to complain if you make a mistake. This is where
  42. : you came in. Note the difference between "not needing to know your
  43. : variable type" and "not needing to know how that variable type is
  44. : implemented on a particular hardware/OS/compiler implementation".
  45.  
  46.  Notice I didn't mention type size for asm or C... And where we not talking
  47.  about debuging already compiled code, right?  I recall we where talking 
  48.  about writting code.
  49.  
  50.  I will repeat:
  51.  
  52.  move.word    (a0)+,(a1)+
  53.  
  54.  I would not write the above if I didn't know a0 and a1 are of the same type.
  55.  
  56.  a++ = b++
  57.  
  58.  I would not write the above if I didn't know a and b are of the same type,
  59.  or a type compatible with C operators, or a type that can be converted..
  60.  
  61.  basicly in both case know the variable type, and type definition.
  62.  
  63.  Thats all I'm saying... I attacked the asm and C person first claim on
  64.  the subject.
  65.  
  66. : >: What are you talking about? <time.h> is provided as part of the
  67. : >: compiler. The compiler is a beast that translates a valid C source
  68. : >: code defining an algorithm for an abstract machine into actual machine
  69. : >: code for an actual machine.
  70.  
  71. : > I'm talking about doing operation on a strcuture element. if the element
  72. : > was defined has a ulong, then one decide its a float you will have to
  73. : > update your code too to use float. 
  74.  
  75. : This is a red herring. If the *type* of an element in a structure is
  76. : given as ulong, then it must be a ulong, it is bound to being a ulong,
  77. : and you can forever more treat it as a ulong. If it's given as a
  78. : bilby, however, and somewhere else a bilby is defined to be a ulong
  79. : (via typedef), then it is only bound to being a bilby and you can only
  80. : treat it like a bilby - you may not treat it as a ulong.
  81.  
  82.  Yes, and I read that clock_t was a ulong... 
  83.  
  84.  Maybe I dont give the image of it but I know C too. (I wont make that claim
  85.  for c++)
  86.  
  87. : Note well, however, that even ulong is an abstract type, and the only
  88. : assumptions you can make about it are those guaranteed by ANSI
  89. : (assuming you want portability, of course). In particular, it is *not*
  90. : guaranteed to be a 32 bit unsigned integer. On a DEC Alpha, for
  91. : example, it's 64 bits. On a 16 bit machine, it could well be 16 bits.
  92. : Look at integer for another example - on a 68000 Amiga with SAS/C, it
  93. : defaults to 32 bits; specify SHORTINTEGERS and it's 16 bits. On a Mac,
  94. : it's 16 bits. Win16 code on a PC, it's 16 bits; compile for Win32 and
  95. : it's 32 bits. The reason for not specifying these sizes is efficiency
  96. : - leaving them undefined allows the compiler writer to choose the most
  97. : efficient representation. Unfortunately, it requires the programmer to
  98. : do more work to make sure the types can hold the values required. It
  99. : would make writing portable code easier if there were int16, int32,
  100. : int64, etc, types, but this is a side issue. :-)
  101.  
  102.  Yes... I rely on ANSI standart of min range assigned ... 
  103.  In asm the range are fixed it just happen to be that way, and nobody 
  104.  bothered to offer a #typedef function.(a Virtual .int type could have been
  105.  created for the 68000 and now be implemented in HW with 64bit register 
  106.  otherwise used has a word or long depanding on your assembler setting)
  107.  I mentioned all that early on in my post. I also mentioned that I write 
  108.  common code for windows & macos, So I would hope to know about making code
  109.  portable...
  110.  
  111. : >: The idea behind clock_t is that it is a data type suitable for storage
  112. : >: of the system's clock's value and certain operations on it. These
  113. : >: operations are defined in an abstract way, independant of a specific
  114. : >: choice what simple type clock_t may actually be.
  115.  
  116. : > you might not care clockt_t went from 32bit long to a 64bit long,
  117. : > but I you would if it become a 32digit bcpl.
  118.  
  119. : It couldn't, because "-" would no longer work; however, if a
  120. : DiffClock() function existed, it could. time_t is a better example.
  121.  
  122.  This is also true for asm... 
  123.  
  124. : >: Dave called it "polymorphism". I call it "data encapsulation". Anyway,
  125. : >: it's a basic concept of decent programming, and not having understood
  126. : >: it is no crime, but one probably shouldn't go around demonstrating it
  127. : >: everywhere in the most embarrassing way. Eh?
  128.  
  129. : > The point he wanted to prove is that you dont need to care about your
  130. : > variable type, and your variable type definition. I just desagree.
  131.  
  132. : This is the problem - he never wanted to prove that. You misinterpreted
  133. : his comments, and have thus far refused to give up your straw man. :-)
  134.  
  135.  Ok then... its just that when I saw something, and one respond "no you
  136.  are wrong" + detail, I like to prove my original point. I fell strong
  137.  about it because this fact ahappen on everyline I write in ASM or C.
  138.  So someone telling me (Or me reading) that I dont have to bother with type
  139.  definition and even variable type after I define:declare them turn my
  140.  world around :)
  141.  
  142.  Stephan
  143.